Discovering and reserving travel solutions

ABSTRACT

A system and method to facilitate discovery and reservation of travel options suitably include routing processing, flight selection processing, and fare validation processing. Flight selection processing generates flight combinations for each routing discovered by the routing processing. Not all flight combinations are allowed to proceed thus permitting better flight combinations to emerge. Fare validation processing loads fares, checks availability, and validates them according to the specifics associated with each fare. A list of low cost travel solutions is returned to a travel consumer.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/167,624,filed Jun. 23, 2011, which claims the benefit of Provisional ApplicationNo. 61/413,922 and No. 61/413,932, both filed Nov. 15, 2010, all ofwhich are incorporated herein by reference.

TECHNICAL FIELD

The present subject matter generally relates to travel, and moreparticularly, relates to discovering and reserving travel solutions.

BACKGROUND

Online travel search providers have revolutionized the travel industry.Over time, these online travel providers have successfully integratedtravel reservation systems to reliably deliver lower fares and realisticitineraries to prospective travelers. Unfortunately, this hastransformed the relationships among participants in the travel industryto be less interdependent. Fees once enjoyed by various industryparticipants have been reduced or eliminated.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to identify key features ofthe claimed subject matter, nor is it intended to be used as an aid indetermining the scope of the claimed subject matter.

One form of the present subject matter includes a method, which recitesa computer-implemented method for a travel request. The method comprisesperiodically calculating, by a processor node associated with acomputer, potential routings and split points for later use in thecreation of theoretical travel paths for potential travel itineraries.The method also obtains, by a search node associated with the computer,a travel request having at least one origination and at least onedestination. The method additionally creates, by a routing moduleassociated with the search node, at least one theoretical travel pathfor a travel itinerary based on the travel request. The methodgenerates, by a travel module associated with the search node, travelcombinations based on the unique travel routings associated with eachtheoretical travel path. The method further provides a list of travelitinerary options from the travel combinations in response to the travelrequest.

DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thissubject matter will become more readily appreciated as the same becomebetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 shows a block diagram view of computer systems in amulti-variable online travel option identification and reservationprocessing environment 100 in accordance with at least one embodiment;

FIG. 2 shows several components of a travel request processing server inaccordance with one embodiment;

FIG. 3 shows several components of a distributed travel requestprocessing front end server in accordance with one embodiment;

FIG. 4 shows several components of a distributed travel requestprocessing back end server in accordance with one embodiment;

FIG. 5 shows system interaction for travel data discovery, selection,and validation in accordance with one embodiment;

FIG. 6 shows a flow diagram for travel request processing in accordancewith one embodiment;

FIG. 7 shows pictorial diagrams illustrating example outputs of arouting process in accordance with one embodiment;

FIGS. 8A-8C and 8E show a process diagram illustrating a method forprocessing flight selections in accordance with one embodiment;

FIGS. 9A-9F show a process diagram illustrating a method for processingfare validation in accordance with one embodiment; and

FIG. 10 shows a flow diagram for travel route reservation processing inaccordance with one embodiment.

DETAILED DESCRIPTION

The detailed description that follows is expressed in terms of softwareprocesses and symbolic representations of operations by hardwarecomputer components, including a processor, memory storage devices forthe processor, connected display devices, and input devices.Furthermore, these processes and operations may utilize computercomponents in a homogenous or heterogeneous distributed computingenvironment, including remote file servers, computer servers, and memorystorage devices. Each of these distributed computing components isaccessible by the processor via a communication network. In aheterogeneous computing environment, clients, servers, andclient/servers may be, for example, mainframes, minicomputers,workstations, or personal computers.

Referring now to FIG. 1, a block diagram view of computer systems in amulti-variable online travel option identification and reservationprocessing environment 100 is shown in accordance with at least oneembodiment. The environment 100 includes client query building nodes110, search node 120, data processor node 140, availability server node150, data storage node 160, and client post-search processing nodes 180.Components in the environment 100 have access to additional data sourcesvia the internet 130 including bus schedule and pricing providers 133,train schedule and pricing providers 135, low cost carrier (LCC)schedule providers 137, global distribution systems (GDS) 155, datasuppliers 165, and live LCC pricing providers 170. The data suppliers165 may provide a variety of information, including data feeds, providedby the Airline Tariff Publishing Company (ATP), the Official AirlineGuide (OAG), the International Air Transport Association (IATA), MinimumConnecting Time (MCT), and other travel-related data feeds. In addition,data suppliers may also provide a variety of travel information directlyfrom the source; for example, specific airports may provide informationpertaining to weather conditions, tax rates, check-in wait times,layover accommodations, on-time flight performance information,interline agreements, currencies, and exchange rates for foreign farecalculations. Travel information collected from the various data feedsand data suppliers may be stored in computer accessible document form ondata storage node 160.

Online travel searches, such as an airfare search, may approach theproblem of finding suitable fares in a variety of ways. Most searchesstart by selecting all flights that have available seats on them andlook for fares applicable to the instant search, if any, and price thosefares. Alternatively, a search might start with fares and attempt toconstruct a combination of fares covering the desired travel path andthen identify the flights based on the fares.

An alternative approach uses routing numbers, a common characteristicbetween available fares of a single carrier, as a starting point foreach fare search. This search configuration allows precalculation oftheoretical travel paths in advance of a particular travel request,thereby significantly reducing the computations needed at the time thetravel request is actually made. To accomplish this type of search,search node 120 maintains a list of routings from each carrier coveringvarious travel options. Search node 120, via data processor node 140,periodically generates a list of suitable routings including each originand destination pair with respective fares. A typical routing listingincludes the routing number, minimal fare price when the routing isused, and permitted miles on that routing. In a more advanced form ofone embodiment, a routing listing might also include possible left andright add-on routings that may be used in combination with the routingbeing listed to reach from the origin to the destination with thespecified routing. In one embodiment, each routing listing is alsoassociated with a group of fares that may be used on that routing. Forexample, in one embodiment, a single routing listing might include aplurality of unique fares that may be available with each routing if therules associated with that fare are satisfied. These fares are oftenincluded with a tariff identification number of the fare that can beused with the routing to get from the origin to the destination, thefare type of the fare, and the estimated adult passenger price for thefare. Examples of fare types include published domestic, publishedinternational, international arbitrary, private, paper, and low costfares. Accordingly, the combination of routings and fares forms thebasis of an accurate simple travel search. For more complex travelsolutions, additional information regarding potential fare combinationsis needed. Accordingly, modern tickets are usually a combination offares, not a single fare.

Both traveler client nodes, namely, client query building nodes 110 andclient post-search processing nodes 180, may or may not be colocated ona single client device. In one embodiment, a traveler may place a travelrequest for travel information on one client device and receive thetravel results on another client device. For example, travel resultsmight be accessible from multiple locations in electronic form, such ase-mail or hyperlink. Both traveler client nodes 110, 180 may beconnected to search node 120 via the internet 130.

Search node 120 receives travel query data, often in the form of atravel query, from client query building nodes 110. Search node 120includes a routing process module configured to find matching routingsfor a received travel query, a travel process module configured to findappropriate travel combinations using the routings matching the travelquery, and a validation process module to validate fares of the toptravel combinations prior to transmitting response data back to thetravel client. Search node 120 is also connected to data processor node140, availability server node 150, and data storage node 160.

Data processor node 140 includes select stored travel data obtained fromdata storage node 160 for suitable routings and split points, flightschedules, fares, rules, routings, tax information, and othermiscellaneous travel data. The routing module of the search node 120selectively accesses stored travel data from data storage node 160relating to suitable routings and split points and associated fares,rules, and routings for the received travel query. The travel module ofthe search node 120 selectively accesses stored travel data from datastorage node 160 relating to flight schedules, associated fares, rules,and routings relating to theoretical travel paths created by the routingmodule in response to the received travel query. The validation moduleof the search node 120 selectively accesses stored travel data from datastorage node 160 relating to tax information, fares, rules, routings,and other miscellaneous travel data relating to suitable travelcombinations generated by the travel module in response to the receivedtravel query.

Availability server node 150 includes stored data reflectingavailability of fares for specific flights. The availability server node150 may obtain live availability data from a variety of providers,including directly from travel providers or via a central reservationsystem, such as GDS 155, including Sabre, Amadeus, Travelport, and ITASoftware. GDS 155, in addition to checking availability, may also allowthe travel client to perform a variety of travel related actions,including making ticket reservations, purchasing/selling tickets formultiple airlines, booking hotel rooms, reserving rental cars, andmaking railway reservations. Both the travel module and the validationmodule of the search node 120 selectively access stored availabilityinformation provided by availability server node 150.

Referring now to FIG. 2, several components of a travel requestprocessing server 200 are illustrated. In some embodiments, travelrequest processing server 200 may include many more components thanthose shown in FIG. 2. However, it is not necessary that all of thesegeneral components be shown in order to disclose an illustrativeembodiment. As shown in FIG. 2, the travel request processing server 200includes a communication interface 230 for connecting to a network,e.g., the internet 130. The travel request processing server 200 alsoincludes a processing unit 210, memory 250, and an optional display 240,all interconnected along with the communication interface 230 via a bus220. The memory 250 generally comprises a random access memory (“RAM”),read only memory (“ROM”), and a permanent mass storage device, such as adisk drive.

The memory 250 stores program code for a travel graph discovery routine400 for periodically calculating potential routings and available splitpoints, a routings routine 500 for determining unique travel routingsand fares for requested travel, a travel routine 600 for generatingtravel combinations from available travel routings, and a validationroutine 700 for checking fares and availability for each travelcombination. In addition, the memory 250 also stores an operating system255. The discovery routine 400 includes a routing generation subroutine.The routing routine 500 includes a theoretical travel path subroutine550 for creating at least one theoretical travel path along a travelgraph for inclusion in a proposed travel itinerary and a searchsubroutine 560 for identifying routings. The validation routine 700includes a fare validation subroutine 750 and an availability subroutine760. These software components may be loaded from a non-transientcomputer readable storage medium 295, on which the software componentsare tangibly embodied, into memory 250 of the travel request processingserver 200 using a drive mechanism (not shown) associated with acomputer-readable storage medium, such as a floppy disk, tape,DVD/CD-ROM drive, memory card, or the like. In some embodiments,software components may also be loaded via the communication interface230, rather than via a computer readable storage medium 295.

These travel related services may be configured so that any computerconnected to the internet 130 is potentially connected to the group oftravel applications, processing units, databases, and files or at thevery least is able to submit travel requests and/or access travelresults. In this manner, the travel request processing server 200 may beaccessible in a variety of ways by a variety of client devices, forexample, a personal computer, a game console, a set-top box, a handheldcomputer, a cell phone, or any other device that is capable of accessingthe internet 130.

Although one embodiment of a travel request processing server 200 hasbeen described that generally conforms to general-purpose computingdevices, a travel request server 200 may be any of a great number ofdevices capable of communicating with other network capable devices.Accordingly, in one embodiment, the travel request processing server 200may be a dedicated server. In another embodiment, the travel requestprocessing server 200 may be a distributed server, such a cloud travelserver (e.g., 300, 400 as described below) providing computationalresources on demand via a network. Available cloud resources may includeapplications, processing units, databases, and file services. In thismanner, the travel request processing server 200 enables convenient,on-demand network access to a shared pool of configurable travel relatedcomputing services and resources (e.g., networks, servers, storage,applications, and services) that can be rapidly provisioned and releasedwith minimal management effort or service provider interaction.Accordingly, one embodiment, deploying a cloud travel server, mayutilize two different computing entities, a front-end server 310A and aback-end server 410B.

Referring now to FIG. 3 (and referentially to FIG. 4), severalcomponents of a distributed travel request processing front end server310A, 410A of a cloud travel server 300, 400 are shown in accordancewith one embodiment. The front-end server 310A, 410A or cloud controlleror controller cluster manages in the midst of the cloud; specifically,the front-end server 310A, 410A handles client interactions with thedistributed server. The configurable nature of a cloud server 300, 400is particularly useful in certain embodiments, particularly as front-endserver 310A, 410A provides the ability scale horizontally. In essence,the number of users making travel requests will not significantly affectthe overall performance of a cloud server configuration as any increasemay be offset by load balancing over many web server front ends. In oneembodiment, a template of front-end server 310A, 410A may be used toactivate additional identical front end cloud servers, which may then beused for load balancing.

The distributed travel request processing front end server 310A, 410Aincludes client travel query building module 320, travel rule engine380, and client post-search processing module 330. Client travel querybuilding module 320 receives query data, often in the form of a travelquery, from a variety of client query building nodes 110.

Once the resulting travel combinations have been discovered, sorted, andavailability confirmed and validated the results are returned to thetravel client via client post-search processing module 390. Clienttravel itinerary selection subroutine 340 enables the traveler to selectand/or reserve at least one of the proposed travel combinations. Clienttravel purchase subroutine 350 enables the traveler to purchase selectedtravel combinations. Client travel itinerary publishing subroutine 360publishes the selected and/or purchased travel combinations toindividuals identified by the traveler. Client travel monitoringsubroutine 370 may review components of the selected or purchased flightfor changes in availability, price, departure/arrival time, and relatedflight conditions (delay/cancellation). In one embodiment, client travelmonitoring subroutine 370 provides reminders for upcoming flightsincluding online check-in notification 24 hours before the flight,recommended on-site arrival times, and existing traveler/passengerregulations. In some embodiments, travel reminders may also includerelated travel information collected directly from the source, forexample specific airports may provide information pertaining to existingweather conditions, tax rates, check-in wait times, layoveraccommodations, on-time flight performance information, interlineagreements, currencies, and exchange rates.

Referring now to FIG. 4 (and referentially to FIG. 3), severalcomponents of a distributed travel request processing back end server410B, 310B of a cloud travel server 400, 300 are shown in accordancewith one embodiment. The back-end server 410B, 310B provides access forthe controller nodes, storage for database information, and processingpower. Accordingly, since the routing discovery routine 420 and splitpoint discovery routine 425 are processing, computing power may beperiodically added to back-end server 410B, 310B when the routines arebeing performed. During these “discovery” periods, the back-end server410B, 310B may temporarily allocate additional computing power dedicatedto the generation of the routing database and split point database. Theresulting pre-calculation data 430 may be used repeatedly by the routingselection routine 440, flight selection routine 450, and fare validationroutine 460. Accordingly, additional memory resources may be allocatedby the back-end server 410B, 310B to cache portions of thepre-calculation data 430 and thereby improve performance.

Routing selection routine 440 creates at least one theoretical travelpath for a travel itinerary based on the travel request. Eachtheoretical travel path uses a combination of at least one traveltemplate and at least one of the origination and the destination; thetravel template includes a travel origination field including either theorigin or destination, split point placeholders, and types of pricingunits. Routing selection routine 440 obtains pre-calculated split pointsassociated with specific travel paths and determines unique travelroutings and fares along each respective theoretical travel path basedon pre-calculated routings associated with each split point. Based onthese unique travel routings, routing selection routine 440 identifiesand selects a portion of the available routings for the specific travelsegments to represent the cheapest routings. Once a group of suitablecheap routings has been identified for a specific travel combination,routing selection routine 440 may further identify and select a portionto represent the cheapest tariffs from within that group. Once uniquetravel combinations have been made using travel routings and fares,flight selection routine 450 selects a group of suitable flights tocover these fare constructions.

The fare validation routine 460 and availability routine 470 worktogether to check whether suitable flights identified by the routingselection routine 440 match travel rules associated with the fares. Thefare validation routine 460 validates suitable fares and/or flights foreach travel combination of each potential path and removes invalidtravel combinations for specific travel dates. Travel combinations maybe invalid for a variety of reasons including rules and restrictionsimposed on the fare by the travel provider. The availability routine 470determines whether all unique flight combinations previously identifiedremain viable travel options. Availability of particular travelcombinations may change for a variety of reasons including sell-out ofseats at the designated fare, flight cancellation, or other dynamicstatus changes that need to be checked.

Particular embodiments of the routing selection routine 440, flightselection routine 450, fare validation routine 460, and availabilityroutine 470 are described in greater detail below with regard to FIG. 5,FIG. 6, FIGS. 8A-C, FIG. 8E, and FIGS. 9A-9F.

Referring now to FIG. 5, system interaction for a travel system 500implementing travel data discovery, selection, and validation is shownin accordance with one embodiment. The travel system 500 includes ruleengine 505, travel server 510, white label interface 590, and multiplethird party information sources including Airline Tariff PublishingCompany (ATPCO) 524, OAG 526, Ticket Tax Box Service (TTBS) 528, andexternal availability sources 580. The travel server 510 includes apre-calculation generator 520 to generate pre-calculation data 530,which includes a routing database and a split point database. Travelserver 510 uses the pre-calculation data 530 to conduct routingselection 540 searches and to make flight selection 550 suggestions fora received query. In one embodiment, the travel server 510 provides farevalidation 560 of selected flights and routes via availability server570 using availability data 575 and information received from externalavailability sources 580.

ATPCO 524 collects and distributes fare and fare-related data for theairline and travel industries. ATPCO 524 also serves as the airfare dataprovider for several airlines worldwide, which together represent amajority of scheduled commercial air travel. Fare information from allthese airlines is also sent to another set of ATPCO customers, includingthe major global distribution systems (e.g., Sabre, Amadeus, Travelport,and ITA Software) and other computer reservation systems that useairfare data from ATPCO 524 to issue tickets. In addition, collectedfare information is also reported by ATPCO 524 to travel agencies,airlines, cargo carriers, governments, and travel industryorganizations. In one embodiment, travel server 510 also receives fareand fare-related data from another source, instead of or in combinationwith ATPCO 524.

OAG 526 provides aviation information and analytical services sourcedfrom proprietary databases tracking a variety of travel informationincluding airline schedules, flight status, fleet, Maintenance, Repairand Overhaul (MRO), and cargo logistics. An independent provider oftravel information products and services, OAG 526 offers a variety ofmarket intelligence on aircraft fleets, capacity supply, traffic demand,financial and operating performance, airline schedules distribution,real time flight status information, timetables, codesharesynchronization, and MRO forecasting. In one embodiment, travel server510 also receives flight information from another source, instead of orin combination with OAG 526.

TTBS 528 provides a travel server 510 with access to all taxes, charges,and fees applied on passenger air transportation. In one embodiment, thetravel server 510 stores tax information separately as a component of afare. In this manner, taxes may be added individually to each path sothat the resulting price is the sum of all fares in the path plus anyIATA taxes associated with each of the cities in the path. In oneembodiment, tax updates are manually input to the travel server 510. Taxupdates are altered infrequently relative to fare prices, and oftenthese changes are unpredictable since each tax entity may have its ownschedule for making tax adjustments. Potential taxing entities mayinclude airport, city, county, state, country, province, region,department, prefecture, district, township, town, borough, parish,municipality, shire, village, and other administrative and regulatoryagencies with authority to levy taxes or impose fees on the travelindustry or affiliated ports of travel. In one embodiment, travel server510 also receives tax information from another source, instead of or incombination with TTBS 528.

The travel server 510 includes a pre-calculation generator 520 toperiodically compose a list of fares that cover each Origin andDestination pair (O&D) that can be reached with available flights. Fromthe list of fares, sorted by price, travel server 510 extracts the moreapplicable unique routings. In one embodiment, the list of fares mayinclude a database storing up to a variety of distinctive fares for eachrouting. For example, Table 1 shows a truncated list for round-triptravel in economy class between Sofia, Bulgaria and Seattle, Wash.:

TABLE 1 Truncated Routings List for Travel between Sofia, Bulgaria andSeattle, Washington Add-on Combination Routing Number Left Right MINFare Price MAX Miles 001BA 2396 — 0073 297 mpm: 7045 001UA 0406 — — 298mpm: 7045 001LH 0406 — — 298 mpm: 7045 001CO 0406 — — 298 mpm: 7045001AC 0406 — — 324 mpm: 7045

Each entry in the list may include a routing number (e.g., “001ba2396”), add-on combination identifications for both left and rightadd-ons, the minimal fare price when this routing is used (e.g., “297”for that specific combination), and the maximum permitted miles on thatrouting (e.g., “7045” miles). In one embodiment, add-on combinations(e.g., “----0073” indicating only a right add-on) are included when theyare to be used to reach from the origin to the destination with thespecified routing at a particular fare and/or price. In one embodiment,the maximum permitted miles on each routing is relatively proportionateto the actual miles to be traveled for travel between origin anddestination along a particular routing. In another embodiment, themaximum permitted miles on a particular routing is related to the travelrange of the aircraft currently assigned to the routings.

Table 2 shows the top two routings from Table 1 along with theirassociated fares:

TABLE 2 Partial List of Routings plus Fares for Travel between Sofia,Bulgaria and Seattle, Washington Routing Number Tariff Number Fare TypeAdult Fare Price 001BA 2396 - - - 0073 739502 0 297 213231 0 351 2131320 442 213218 0 450 213151 0 489 001UA 0406 - - - 2948466 0 298 2711482 0331 2711486 0 371 2711481 0 424

Each entry in the list of Table 2 may include a routing number withadd-ons (e.g., “001ba 2396----0073”), a subset listing the tariff numberof each fare that can be used with this routing to get from the originto the destination (e.g., “739502”), the fare type of each fare, and theestimated adult passenger price for each fare (e.g., “297”). In oneembodiment, travel server 510 distinguishes a variety of the fare typesincluding the following: published domestic, published international,international arbitrary, private, paper, and low cost fares.

In one embodiment, these lists are periodically refreshed to confirm ormodify the information. To maintain accuracy, portions of thepre-calculated data 530 may be generated whenever new information isobtained by the travel server 510. For example, in one embodiment, dailygeneration of the routings database and the split point database maystill produce satisfactory results as most travel vendors infrequentlyupdate fare information and flight plans. In contrast, availability oflisted fares is often validated by the availability server 570 morefrequently, especially as booking classes may be sold out.

Referring now to FIG. 6, a flow diagram for travel request processing isshown in accordance with one embodiment. The travel request processingroutine 1300 illustrates creation of priced travel options based on atravel request. In one approach, the routine 1300 uses a common propertybetween each of the fares of a single carrier to improve the speed andquality of search. More specifically, routine 1300 may use the carrierassigned routing number as a starting point of each fare search. To dothat, the routine 1300 needs access to a list of routings from thecarriers that are capable of covering each and every search that willever be searched. In one embodiment, this list of routings is availableto the routine 1300 via the precalculated data (e.g., 430, 530).

In block 1310, a new travel request is received by the routine 1300.Routine 1300 obtains a travel request 1320 which may include informationpertaining to origination, destination, travel dates (includingdeparture and return), passenger information (including the number ofpassengers), and a variety of other travel options. Some travel optionsmay include split point preferences, layover parameters, plane sizerequests, special needs such as food allergies or diet restrictions, andmeal preferences. In subroutine block 1330, routine 1300 validates thetravel request. This validation is checking whether the travel consumerhas the right to do the search requested, or whether they have the rightto use the data requested, the tickets their suppliers can issue, and soon.

In subroutine block 1340, routine 1300 selects preferred routings,travel paths, and split points associated with the origination and/ordestination of the received travel request. In one embodiment, routine1300 retrieves information from precalculated data (e.g., 430, 530)including routings information from the routings database and splitpoint information from the split point database pertaining to possibleroutings and split points for every city in the travel request. FIG. 7discusses the output of the subroutine 1340 in greater detail.

Upon identifying the most likely travel paths, routine 1300 selectstravel combinations that can cover the travel request in subroutine1350. More specifically, subroutine 1350 limits the selected travelcombinations to those routings with flights that are currently capableof covering travel particulars given in the travel request 1320including travel dates, passenger quantity, and travel preferences.FIGS. 8A-8E discuss the subroutine 1350 in greater detail.

In subroutine 1360, routine 1300 selects the travel combinationsidentified by subroutine 1350 that exhibit the lowest fares. The size ofthis list may vary according to the original parameters of the receivedtravel request 1320. Once the preliminary selections have been made,routine 1300 validates the selections against the rules and pricerequirements to determine whether the proposed travel request qualifiesfor the fare. In one embodiment, if a portion of the travel combinationis discovered in subroutine 1370 to be invalid because that particularportion does not qualify for a specific fare, then an alternativesubstitute travel portion may be used. One embodiment requires that thecost of the substitute travel portion be less than or equal to the costof the invalidated portion. If the substitute travel portion is cheaperthan the invalidated portion, then the total fare price is recalculatedfor the new travel combination. In another embodiment, an invalid farediscovered in subroutine 1370 is removed from the selection list. Thisembodiment attempts to minimize calculations after the travel requesthas been made and assumes that one of the other possible fares selectedin subroutine 1360 will include the cheapest valid fare. FIGS. 9A-9Fdiscuss the subroutines 1360, 1370, in greater detail.

Upon validation, routine 1300 generates a list of priced itineraries1380 from the remaining valid fares. The list of priced itineraries 1380includes at least one travel option responsive to the travel request1320. In one embodiment, the parameters of the list may be defined inpart by the travel request 1320. Other parameters of the list may bedictated by the validated results from subroutine 1370. In block 1390,routine 1300 returns the list of priced itineraries 1380 to the travelerinitiating the travel request 1320.

FIG. 7 shows pictorial diagrams illustrating example outputs of arouting process in accordance with one embodiment. For illustrativepurposes only, FIG. 7 shows outputs of an exemplary query by a travelconsumer who desires to travel from Chicago, Ill. (CHI), to Los Angeles,Calif. (LAX). The output of the routing module comprises pricing unitcombinations, each with its fare components, each of which has itsroutings and fares identified.

The shape of the pricing units and their fare components are likely todiffer from query to query. In each query, the routing output generatesas many suitable mathematical shapes that are feasible and includes oneshape comprised of one round trip fare and one shape comprised of twoone-way fares in two separate pricing units. The shapes of the pricingunits are illustrated by the pictorial diagrams of FIG. 7.

Diagrams 702-710 illustrate five distinct pricing unit combinations andshapes. These may be couched as “trips”, “journeys”, or“trips/journeys”. In each journey the numbering of the pricingcomponents (one way “OW”, round trip “RT”, open jaw “OJ”) is indicativeof the pricing unit in which they will be placed. For example, thediagram 708 represents two pricing units, each with its OJ farecomponent. To complete the journey, all pricing units are suitablyvalidated. Whether the journey will result in a split ticket or not isdetermined at a later stage. Each of those journeys will have routingand fare combinations associated with it.

FIGS. 8A-8C and 8E illustrate a method for processing the flightselection module. From a starting block (FIG. 8A), a method 800 proceedsto block 802 where the method begins to generate flight combinations fora routing. The method continues to another continuation terminal(“terminal A1”). Next, at block 804, each trip/journey from the routingmodule is divided into blocks. The method then continues to anothercontinuation terminal (“terminal A2”). Next, at block 806, each blockcontains a list of routings. The method then continues to yet anothercontinuation terminal (“terminal A3”). Proceeding to block 808, for eachrouting, a list of paths/routes is generated (suitably from shortest tolongest) according to different carriers and cities. Continuing to block810, the method receives flight schedule information from aviationdatabases, such as OAG. At block 812, a set of flight combinations isgenerated from each routing and each path, according to dates,schedules, carriers, and flight numbers. The method 800 then continuesto yet another continuation terminal (“terminal A4”).

From terminal A4 (FIG. 8B), the method 800 proceeds to decision block814 where a test is performed to determine whether there are moreroutings within a block. If the answer to the test at decision block 814is YES, the method 800 continues to terminal A3 and skips back to block808 where the above-identified processing steps are repeated. Otherwise,if the answer to the test at decision block 814 is NO, the methodcontinues to decision block 816 where another test is performed todetermine whether there are more blocks within a trip/journey. If theanswer to the test at decision block 816 is YES, the method continues toterminal A2 and skips back to block 806 where the above-identifiedprocessing steps are repeated. Otherwise, the answer to the test atdecision block 816 is NO, and the method continues to decision block818, where a further test is performed to determine whether there aremore trips/journeys. If the answer to the test at decision block 818 isYES, the method continues to terminal A1 and skips back to block 804where the above-identified processing steps are repeated. Otherwise, theanswer to the test at decision block 818 is NO, and the method continuesto a continuation terminal (“terminal A5”).

From terminal A5 (FIG. 8C), the method 800 proceeds to block 820 wherethe method begins to sort flight combinations within each routing. Themethod then proceeds to a continuation terminal (“terminal A6”). Atblock 822, the method calculates a sorting coefficient, which is appliedto each flight combination based on availability, travel time, number ofconnections, significant carrier, and carrier alliances. The method thencontinues to another continuation terminal (“terminal A8”).

From terminal A8 (FIG. 8E), the method 800 proceeds to decision block850 where a test is performed to determine whether there are moreroutings. If the answer to the test at decision block 850 is YES, themethod continues to terminal A6 and skips back to block 822 where theabove-identified processing steps are repeated. Otherwise, the answer tothe test at decision block 850 is NO, and the method proceeds to block852. At block 852, the method sorts the flight combinations according totheir sorting coefficients. At block 854, the method begins to combineflight combinations among blocks. The flight combinations of routingsamong blocks are combined so that each combination of flightcombinations has one flight combination from each block. See block 856.At block 858, travel limits, restrictions, and tolerances of flightcombinations of one block are combined with other travel limits,restrictions, and tolerances of other blocks that then compose atrip/journey. The method then exits and terminates execution. At theexit, the output of the flight selection module is where a list ofunique combinations of flight combinations for each routing combinationis produced within each journey/trip. See FIG. 7.

FIGS. 9A-9F illustrate a method for processing fares validation. From astart block (FIG. 9A), a method 900 proceeds to block 902 where themethod obtains from the routing module a list of routing combinationscontained in each trip/journey. The method obtains from the flightmodule flight combinations within each routing combination. See block904. At block 906, the method calculates a coefficient, which controlsthe maximum number of flight combinations within routing combinationsfor trips/journeys that will be allowed to the fare validation module.To keep diversity of routings and carriers, the maximum number of flightcombinations is dependent on the increase in the number of routingcombinations and flight combinations. See block 908. At block 910, themethod loads fares for each fare component for each trip/journey fromthe airline tariff publishing company or from any suitable sources. Themethod 900 does not process fares which were found as not valid in therouting module. See block 912. At block 914, the method may elect tosearch specific discount fares. The method then continues to anothercontinuation terminal (“terminal B1”).

From terminal B1 (FIG. 9B), the method 900 finds a specific booking code(reservation/booking designator “RBD”) and checks for its availability.See block 916. At block 918, the method queries the availability server,which, in one embodiment, uses prediction logic to check availability.Proceeding to block 920, if there is no response to the query, themethod reaches out to an external data source, such as a computerreservation system, to get availability information. The method thencontinues to decision block 922 where a test is performed to determinewhether there is availability information. If the answer to the test atdecision block 922 is YES, the method 900 continues to anothercontinuation terminal (“terminal B2”). Otherwise, the answer to the testat decision block 922 is NO, and the method proceeds to block 924 whereit removes the fare because there is no seat availability for the farebooking code for one of the flights in the combination. The method thencontinues to terminal B2.

From terminal B2 (FIG. 9C), the method validates fares against farecomponent level categories. See block 926. At block 928, the methodvalidates fares against passenger categories for each passenger. Themethod searches each pricing unit for a list of air components, each ofwhich has a list of valid fares. See block 930. Within each pricingunit, combinations of fares are created where each fare combination hasone fare for each fare component, up to a predetermined maximum amount.See block 932. At block 934, the method validates fares against pricingunit categories. Proceeding to block 936, the method attaches a listwith validated pricing units to each passenger in an itinerary. Next, atblock 938, the method searches passengers for a list of differentpricing units and further searches each of the pricing units for farecombinations. The method then continues to a continuation terminal(“terminal B3”).

From terminal B3 (FIG. 9D), the method 900 proceeds to block 940 where,for each passenger, the method combines a low fare combination from onepricing unit with low fare combinations from other pricing units to finda travel solution in the itinerary. Proceeding to block 942, the methodlimits the number of combinations in all flight combinations for allpassengers as a function of the number of passengers. The method checksavailability for a booking code for each passenger for each segment ofthe travel solution. See block 944. Proceeding to decision block 946, atest is performed to determine whether there is availability. If theanswer to the test at decision block 946 is YES, the method proceeds toanother continuation terminal (“terminal B4”). Otherwise, the answer tothe test at decision block 946 is NO, and the method proceeds to block948 where the method removes the travel solution. The method thencontinues to terminal B3 and skips back to block 940 where theabove-identified processing steps are repeated.

From terminal B4 (FIG. 9E), the method proceeds to decision block 950where another test is performed to determine whether there are morepassengers. If the answer to the test at decision block 950 is YES, themethod continues to terminal B3 and skips back to block 940 where theabove-identified processing steps are repeated. Otherwise, the answer tothe test at decision block 950 is NO, and the method proceeds to block952 where the method validates travel solutions against discountcategories and makes updates to the fare combinations. The method thenadds taxes to the travel solutions. See block 954. At block 956, fromthe list of remaining validated travel solutions, the method checksavailability for a small set of the most inexpensive travel solutions.The method then continues to another continuation terminal (“terminalB5”). Proceeding to block 958, the method selects a solution for eachjourney/trip using the list of remaining travel solutions and a smallset of the most inexpensive travel solutions. One suitable small setincludes five travel solutions that are the most inexpensive travelsolutions. The method then continues to another continuation terminal(“terminal B6”).

From terminal B6 (FIG. 9F), the method continues to decision block 960where a test is performed to determine whether the solution limit hasbeen reached. If the answer to the test at decision block 960 is YES,the method proceeds to terminal B5 and skips back to block 958 where theabove-identified processing steps are repeated. Otherwise, the answer tothe test at decision block 960 is NO, and the method proceeds to block962 where the method filters the available solutions under price rangelogic. Proceeding to block 964, the method outputs the filteredsolutions which start from the most inexpensive fares to progressivelymore expensive fares for the itinerary, or by any other suitablefilters, such as flight times or connection preferences. The method thenenters an exit terminal and terminates execution.

Referring now to FIG. 10, a flow diagram for a travel route reservationprocess is shown in accordance with one embodiment. The travel routereservation process routine 1500 selects the most suitable ATPCO faresin block 1510 in accordance with the received parameters of the travelrequest. Availability of a selected fare is checked in block 1520 byroutine 1500 against cached fare availability data typically managed byan availability server (see, e.g., 150 or 570). In one embodiment, thetop results exhibiting real availability are priced and returned inblock 1530 by routine 1500. Accordingly, the remaining price travelsearch results may then be displayed to the user in block 1535 byroutine 1500.

If the displayed results are agreeable to the user, then a bookingsolution may be selected by the user in block 1540. Once routine 1500obtains a fare selection in block 1540, the selected fare is validatedin query block 1550 by verifying seat availability and price. If theselected fare is validated, routine 1500 creates a Passenger Name Record(PNR) in block 1560 in the database of a CRS that contains the itineraryfor a passenger, or a group of passengers traveling together. Otherwiseroutine 1500 updates the availability cache. In one embodiment, if analternative price is available for the selected fare, routine 1500 mayoptionally include the new price when notifying the user. If the newprice is accepted by the user in query block 1557, routine 1500 createsa PNR in block 1560. If the new price is not accepted in query block1557, routine 1500 ends. In one embodiment, after removing the invalidselection, routine 1500 optionally returns to the remaining searchresults in block 1530 to enable the user an opportunity to selectanother fare. Once a PNR has been created for the selected fare, routine1500 verifies payment in query block 1570. If payment cannot beverified, routine 1500 cancels the PNR in block 1575 that was originallycreated in block 1560. Otherwise routine 1500 finalizes the PNR in block1580 and notifies the agency to issue a ticket for the purchased fare.

Upon returning the priced results in block 1530, in one embodiment,routine 1500 may enter an optional private label or white label module290 where the travel search results of the travel server may berebranded by a marketer's to appear as if the travel results originatedfrom the marketer site. This rebranding process may enable a successfulbrand to offer an online travel option identification and reservationprocessing service without having to invest in creating the searchoptimization technology and associated infrastructure. The travel servermay also adjust the scope of search according to the source originatingthe travel request. For example, if an airline carrier redirects apotential passenger to the routing search engine, then the travel servermay restrict the scope of the initial search to routings directlycorresponding to the airline carrier. In one embodiment, the scope ofthe search may also be expanded to include alliance affiliates of theairline carrier, so the search results may be expanded from the flightsoffered by the carrier but still limited to flights operated by theairline carrier and/or alliance affiliates of the airline carrier. Inanother embodiment, travel consolidators may wish to repackage thetravel results in accordance with their brand image.

While illustrative embodiments have been illustrated and described, itwill be appreciated that various changes can be made therein withoutdeparting from the spirit and scope of the subject matter.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. A computer-implementedmethod for a travel request, the method comprising: periodicallycalculating, by a processor node associated with a computer, potentialroutings and split points for later use in the creation of theoreticaltravel paths for potential travel itineraries; obtaining, by a searchnode associated with the computer, a travel request having at least oneorigination and at least one destination; creating, by a routing moduleassociated with the search node, at least one theoretical travel pathfor a travel itinerary based on the travel request; generating, by atravel module associated with the search node, travel combinations basedon travel routings associated with each theoretical travel path; andproviding a list of valid travel itinerary options from the travelcombinations in response to the travel request.
 2. The method of claim1, wherein the creating includes using a combination of at least onetravel template and at least one of the origination and the destination,the travel template including a travel origination field includingeither the origin or destination, split point placeholders, and types ofpricing units.
 3. The method of claim 2, wherein the types of pricingunits include at least one of One-Way (OW) templates, Round-Trip (RT)templates, Origination Open Jaw (OOJ) templates, Destination Open Jaw(DOJ) templates, Open Departure Open Jaw (ODOJ) templates, and circletrip (CT3, CT4) templates.
 4. The method of claim 2, wherein each traveltemplate provides the routing module with building information fortheoretical travel paths from a routing database that includes suitableroutings, fares, and split points.
 5. The method of claim 1, furthercomprising validating, by a fare validation module, each pre-calculatedrouting of a unique travel combination.
 6. The method of claim 5,wherein the validating includes checking, by the fare validation module,availability of each travel combination.
 7. The method of claim 1,wherein the generating includes correlating, by the routing module, theunique travel routings into at least one unique travel combination foreach theoretical travel path.
 8. The method of claim 1, furthercomprising sorting, by the travel module, the travel combinations inaccordance with travel parameters associated with the travel request. 9.The method of claim 8, wherein sorting includes selecting the mostreliable travel combination.
 10. The method of claim 8, wherein sortingincludes selecting travel combinations matching traveler parameters ofthe traveler originating the travel request.
 11. The method of claim 1,wherein the periodically calculating includes obtaining pre-calculatedfares associated with each pre-calculated routing and the determiningincludes selecting price travel routings based on the pre-calculatedfares associated with each pre-calculated routing.
 12. The method ofclaim 1, further comprising: calculating, by the routing module, a pathprice representing a minimum cost for each of the theoretical paths bycombining costs of each of the travel routings in a respective travelcombination, travel routing cost being based on the pre-calculated faresassociated with each pre-calculated routing; and obtaining, by a faresvalidation module associated with the computer, a set of valid faresassociated with each travel routing in a respective travel combinationand determining whether the calculated path price matches availableseats for each respective travel combination.
 13. The method of claim12, wherein the calculated path price includes tax information from atax database to calculate a more accurate total travel price using taxesassessed along the respective travel combination.
 14. The method ofclaim 12, wherein the obtaining, by the fares validation module,includes validating a fare associated with a specific booking code foreach travel routing in a respective travel combination and furthercomprises checking, by the fares validation module, seat availability ofeach fare and selecting only the cheapest valid fare with free seats ina respective travel combination.
 15. The method of claim 12, wherein thecalculated path price for each respective travel combination includes atotal cost value, calculated in the travel module, that adds the pathprice to estimated extra costs, the estimated extra costs includinglodging, transportation, and meal price estimates.
 16. The method ofclaim 15, wherein the estimated extra costs are calculated in the travelmodule based on whether the respective travel combination includesovernight layovers, long layovers, or changes in airports within adesignated city.
 17. The method of claim 12, wherein the providing thelist includes sorting the travel itinerary options by the relative validcalculated path price of each respective travel combination.
 18. Themethod of claim 1, wherein each split point has at least two connectingsegments, an incoming segment and an outgoing segment.
 19. Anon-transient computer-readable medium having tangibly stored thereoninstructions that, when executed by a processor, perform the method ofclaim
 1. 20. A computing apparatus comprising a processor and a memoryhaving stored thereon instructions that, when executed by the processor,perform the method of claim 1.